home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1996 May: Tool Chest / Developer CD Series May 1996 (Tool Chest) (Apple Computer) (1996).iso / Tool Chest / Development Tools & Languages / Macintosh Common Lisp Related / Think C interface / THOUGHTS < prev    next >
Encoding:
Text File  |  1994-09-12  |  2.2 KB  |  45 lines  |  [TEXT/CCL2]
  1. The little book about interfacing MCL and ThinkC
  2. (and in general, about interfacing two langages)
  3.  
  4. Here are some thoughts that grew out of my trials and errors
  5. when I started interfacing MCL and ThinkC:
  6.  
  7.   When you decide to interface two langages that are not compatible
  8.   in respect to data representation, you will have to make some choices.
  9.  
  10.   You can either allocate your data structures all in the first langage
  11.   format, all in the second langage format, or a mixture of both.
  12.  
  13.   In either case, when one of the two langage needs to read data that
  14.   was not allocated in its format, the code will be a little awkward
  15.   and a little bit less efficient because of the necessary conversions.
  16.  
  17.   All this to say that the first step is a carefull planning of how you
  18.   implement your data structures.
  19.  
  20. Here are a few tips one the pros and cons of data structure allocation
  21. in both MCL and ThinkC:
  22.  
  23.   If you allocate structures in C (in the mac heap that is), you will
  24.   have to do yourself all the job that Lisp normally does for you. i.e.
  25.   allocating the memory, releasing it, etc... This is pretty painfull
  26.   but it is the concession you have to make, if you want blazingly fast
  27.   C code. Also this approach lets you write nice C code since the data
  28.   is in a format that it understands readily. Another drawback of this
  29.   approach is that your data is not typed anymore, so the Lisp environment
  30.   wont be abble to display it intelligently. i.e. All your data will
  31.   look like #<A Mac Zone Pointer Size 12 #x7DDDC4> which doesnt make
  32.   debugging very easy...
  33.  
  34.   Allocating your structures in Lisp gives you all the benefits of Lisp
  35.   but makes your C code harder to write and somewhat less efficient. But
  36.   even then your C code should run faster than the Lisp equivalent because
  37.   it wont need to do any type checking, and will also run in constant memory
  38.   so it won't garbage collect.
  39.  
  40.   The ideal solution is probably to really well isolate the computationally
  41.   expansive parts of your code and transfer only those in C. Since the C code
  42.   you define is not user interruptible, it is best to define small
  43.   functions rather that large ones (so Lisp gets a lot of occasions to
  44.   manage user events).
  45.